pouët.net

Tango, the British Amiga scener (formerly in Nerve Axis and a bunch of other groups), came back from a long hiatus a few weeks ago and released a new ASCII collection. You can view it online with original Amiga fonts and download it at AsciiArena. Hopefully there will be more!

[Submitted by dipswitch]

With a massive delay: we present recordings of the Evoke 2025 Seminars. Unfortunately we had a issue with the sound of the seminar by Bodo / Rabenauge. This is why we present only two recordings:

The Art of Coding Lightning talks

GRADE-Panel - Digital Subcultures in Times of Crisis

[Submitted by dipswitch]

All the latest news, links and releases from the active demoscene community. This week in particular we take a look at the releases from Fioniadata in Denmark. Watch on youtube.

[Submitted by psenough]

[ Atariscne.org - News ] GCC for asm Experts (and C/C++ Intermediates) - Part 1

This is a brain dump of what I have learned working with the GCC m68k backend, and maybe an attempt to convince someone else to try. This is the first of an unknown number of posts. No promises for how many there will be; I will continue as long as I have something to say and I find it fun.

I got my start with STOS Basic on an Atari 520STfm around 1990. Me and my classmate Tam formed T.O.Y.S. (Terror on Your ST) and I dubbed myself PeyloW. But in the scene, elite sceners wrote assembly; only lamers used STOS or GFA, every scroll text was clear about this. So we bought DevPac 2 and taught ourselves 68000 assembly, starting with snippets embedded in STOS and eventually graduating to full demo screens. The pattern that would follow me for decades was established early: high-level languages for tooling, assembly for anything that had to be fast. STOS gave way to PurePascal in the late '90s, but assembly remained the language that mattered — right through to the Falcon030 demo "Wait", released at EIL 2001.

My active participation in the scene waned, but I never lost sight of it. For years I stayed as an observer, following releases and discussions from the sidelines. Then around 2021 I had an itch, maybe a mid-life crisis: get back to the simpler machines (the kind a single person can keep entirely in their head) and realize a teenage dream of publishing a completed game. C and C++ had become my main languages through University and work, and modern cross-development tools meant I could use them for Atari too. Not just for tooling, but as the scaffolding of the entire project, dipping into assembly only for the bottlenecks. And as my friend AiO likes to joke: C is just a really powerful macro assembler.

GCC Is (No Longer) Written for Us

The m68k was one of GCC's first backends, present alongside VAX in the 1987 GCC-1.0 release. For a long time it was a first-class citizen. But the world moved on, and the backend fell into disrepair, barely in maintenance mode, with no one actively working on it.

To be fair, the great strides made in modern compiler optimization are what keep the m68k backend limping along. For most codebases the result is on par with yesteryear, even if it completely fails at many of the specifics. Even a 68060 fitted into a Falcon with a CT63 is ancient by modern CPU standards. The optimizations that GCC's middle-end applies (instruction scheduling, loop transformations, register heuristics and reordering) are tuned for modern highly parallel superscalar CPUs, and when they miss on m68k, they miss badly.

Take the inner loop of a simple memory copy (mikro will recognize this one), in C:

*dst++ = *src++;
*dst++ = *src++;
*dst++ = *src++;
*dst++ = *src++;

Any experienced m68k programmer would expect (a0)+ and (a1)+, post-increment addressing, the most natural idiom on our architecture. The compiler should be able to generate this just as-is — it is how the code reads. Here is what stock GCC-15.2 produces at -O2:

.L3:
    move.l (%a0),(%a1)        | plain indexed, no post-increment
    move.l 4(%a0),4(%a1)
    move.l 8(%a0),8(%a1)
    lea (16,%a0),%a0          | pointer update separated from accesses
    lea (16,%a1),%a1
    move.l -4(%a0),-4(%a1)   | negative offset — the lea moved too early

The perfectly fine inner loop gets butchered in the name of scheduling for superscalar execution. Instructions get reordered, pointer increments get separated from their memory accesses, and the fourth copy ends up using a negative offset because the lea was hoisted above it. The result is slower and larger than what GCC-2.95 would have produced, and not even close to what an elite scener would have written. For command-line tools and utilities this is tolerable. For realtime demos and games, it is not.

And Yet — GCC Can Work for Us

But there is light at the end of the tunnel.

Just finished AmiParty 35.

https://demozoo.org/parties/5587/

[Submitted by stefkos]